One of the biggest security vulnerabilities in modern TCP/IP networks is reliance upon Dynamic Host Configuration Protocol, or DHCP. Without DHCP, a computer user attempting to join a network may be required to locate the human network administrator to request an IP address, subnet mask, Domain Name Service (DNS) server address, and other network configuration settings, and the user must manually configure the network stack of the computer to use such settings.
Such a manual approach is often impractical and sometimes impossible, and DHCP may be used instead to configure devices on a network. Using DHCP, a client computer wishing to join a network announces its desire to locate a suitable DHCP server by broadcasting a DHCP Discovery request packet. DHCP servers on the network typically respond with a DHCP Offer packet, which may include the network configuration information for the client, including parameters such as the proposed network address, subnet mask, addresses of additional resources such as gateway routers and DNS servers, and other useful information. The client can then select from among the received offers and respond with a request to Reserve the offered configuration, and the offering DHCP server may finalize the reservation and update its address tables accordingly.
The use of DHCP as described may include certain weaknesses and may have the potential to cause certain security issues within a network. First, there is no provision for limiting which hosts may act as a DHCP server on a given network or subnet, and the DHCP protocol does not offer any means to specify which server is the definitive or even preferred DHCP server for a given network or subnet. As a result, clients receiving offers from two or more DHCP servers must decide for themselves whether a DHCP Server on the network is legitimate and whether any DHCP server on the network may be a security threat. Second, the network stacks in many clients simply accept the first DHCP response offer received since (1) many networks typically have only a single DHCP server, (2) many client devices seek to connect to the network as quickly as possible, and (3) there may often be no way to know in advance how many DHCP servers are present on a network subnet, and therefore how many DHCP offers to expect. Accordingly, many clients make no effort to determine if a DHCP Offer response is received from a legitimate or authorized DHCP server on the network, a DHCP server that has been accidentally inserted into the network or unintentionally configured to provide DHCP service, or a rogue DHCP server potentially operated by a hacker with malicious intent.
For example, a “rogue” DHCP server may be inserted into the public network of a business such as an Internet café by a hacker in order to provide vulnerable configuration information on the network. Upon a client device's request for DHCP information, the hacker's rogue DHCP server may respond to the client prior to a legitimate DHCP server on the network. In some cases, the rogue DHCP server's offer can instruct the client to use insecure or otherwise rogue servers for the client's gateway, DNS server, or for any other network information typically provided by a DHCP server. In this manner, a hacker may direct the client to dangerous network resources, such as counterfeit websites, servers capable of intercepting account names and passwords, and other services that may perform other types of nefarious activity virtually undetectable by the client.
In this example, after a hacker has set up his rogue DHCP server on a network, a customer with a mobile phone could attempt to join the network. When the mobile phone broadcasts a DHCP Discovery request, it may receive DHCP Offer responses from the legitimate router on the network and from the hacker's rogue server. If the hacker's rogue server response is the first received by the customer, then it is likely that mobile phone will configure its network information based on the information supplied by the hacker.
In this example, the hacker's rogue DHCP server may assign the customer a DNS Server address different than the legitimate one on such network. If the mobile phone visits a website of no interest to the hacker, then the hacker's DNS server may forward the request on to the legitimate DNS server, and upon receiving a reply, the customer's mobile device may browse to the requested webpage unaware that anything unusual is taking place.
However, if the mobile phone user decides to visit a specific website targeted by the hacker, then when the mobile phone transmits that domain name in a DNS query, the invalid DNS server configured by the hacker's rogue DHCP server can respond directly with an IP address that may be a counterfeit or “phishing” website. The mobile phone user's web browser will then attempt to load a web page that it believes is coming from a trusted host server on the network or on the public Internet, when in reality the page may be actually coming from a forged website operation by the hacker. If the page is very similar to the actual webpage the user requested, the user may believe that he or she has successfully reached such website when, in fact, it is a potentially dangerous website. By such mechanism, the hacker may be able to perform a variety of dangerous or otherwise insecure actions, such as potentially capturing the user's credentials (such as username and password) as they are entered into the counterfeit web page.
Accordingly, by supplying the winning DHCP Offer from an unauthorized DHCP server, a hacker can direct a victim to virtually any host or server for virtually any purpose. And, by blindly accepting the rogue DHCP Offer response on the network, the customer may accordingly have his or her entire network traffic managed, tracked, and manipulated by any such hacker or other nefarious entity.
Accordingly, there is a need to provide a reliable means of client-side defense against rogue DHCP servers at a network client device.